home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-dns-idpr-00.txt
< prev
next >
Wrap
Text File
|
1993-03-23
|
6KB
|
162 lines
INTERNET DRAFT
DNS Support for IDPR
22 March 1993
Rob Austein
Epilogue Technology Corporation
sra@epilogue.com
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress." Please check the 1id-abstracts.txt listing
contained in the internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to
learn the current status of any Internet Draft.
This is a working document only, it should neither be cited nor quoted
in any formal document.
This document will expire before 09-22-1993..
Distribution of this document is unlimited.
Please send comments to the author.
1. Introduction
This note documents the support needed from the Domain Name System
(DNS) by Inter-Domain Policy Routing (IDPR). The DNS changes are
minor and can be deployed with minimal impact on the installed DNS
community.
When an IDPR Policy Gateway receives an IP packet, it needs to map the
packet's IP address to an IDPR Administrative Domain (AD) in order to
deliver the packet. The initial prototype implementation of IDPR used
a configuration file to provide this mapping, but this is clearly
unacceptable for a full-scale deployment of IDPR. As an existing,
well understood, (relatively) low-overhead distributed database, the
DNS is the obvious mechanism by which to distribute these mappings.
Due to an unfortunate collision in use of the term "domain" by both
IDPR and the DNS, this note avoids unqualified use of the term
"domain."
2. The AD RR type.
We define one new DNS RR type, with symbolic name "AD" and numeric
value xxx. This RR type is class-independent; the rest of this note
discusses IN class AD RRs, with the understanding that the mechanism
described here is not tied to IP addresses. The RDATA portion of an
AD RR consists of two 32-bit integers, each representing an IDPR AD.
The two fields are the "home" AD associated with the address, and the
proxy AD associated with the address. An AD which is acting as its
own proxy (the normal case) has the same value for these two fields.
Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
space. These RRs are used to map from an IP address to an IDPR AD.
We expect that it will be possible to make heavy use of "wildcard" DNS
names here, since we expect that all the hosts on a given IP network
(or subnetwork) are likely to belong to a single IDPR AD.
For purposes of discussion, assume that Miskatonic University is in
Administrative Domain 42, while Engulf & Devour, Inc., is in
Administrative Domains 666 and 17; Engulf & Devour recently purchased
Liver Donors Ltd., in order to use their Policy Gateway as a proxy for
Engulf & Devour's corporate network. The following RRs might appear
in the DNS:
Loki.Miskatonic.EDU. IN A 1.1.1.5
Thor.Miskatonic.EDU. IN A 1.1.1.6
Liver-Donors.EaD.COM. IN A 2.2.2.7
HQ.EaD.COM. IN A 3.3.3.8
5.1.1.1.IN-ADDR.ARPA. IN PTR Loki.Miskatonic.EDU.
5.1.1.1.IN-ADDR.ARPA. IN AD 42 42
6.1.1.1.IN-ADDR.ARPA. IN PTR Thor.Miskatonic.EDU.
6.1.1.1.IN-ADDR.ARPA. IN AD 42 42
7.2.2.2.IN-ADDR.ARPA. IN PTR Liver-Donors.EaD.COM.
7.2.2.2.IN-ADDR.ARPA. IN AD 666 666
8.3.3.3.IN-ADDR.ARPA. IN PTR HQ.EaD.COM.
8.3.3.3.IN-ADDR.ARPA. IN AD 17 666
In this case the AD RRs for Miskatonic University could usefully be
collapsed into a wildcard RR:
*.1.1.1.IN-ADDR.ARPA. IN AD 42 42
3. Use of the AD RR type.
In the initial deployment of of IDPR, we believe that only IDPR Policy
Gateways will need to know about IDPR ADs. Thus, only Policy Gateways
will need to obtain and use AD RRs. In the long run it may be
beneficial for hosts to obtain this data as well, but it is not
necessary that they do so in order for IDPR to work correctly.
4. Bootstrapping the Policy Gateways
Since a Policy Gateway needs an AD before it can forward a packet, the
AD associated with the IP addresses of each of the Policy Gateway's
default DNS name servers needs to be part of the Policy Gateway's
configuration. Ie, there is a bootstrapping problem here, because we
can't use the DNS to obtain the ADs we need in order to talk to the
DNS. Note that the Policy Gateway's default DNS name servers are not
necessarily the root DNS name servers; indeed, clever use of
centralized DNS caches by a community of Policy Gateways will help
decrease the load IDPR will add to the existing DNS system.
Ultimately, however, this question reduces to the question of how the
Policy Gateways reach the DNS root servers.
5. Glue RRs
Since in some cases the authoritative nameservers for a particular AD
RR may be within the AD itself, it may be necessary to insert "glue"
AD RRs into some zones in the IN-ADDR.ARPA tree. These fill the same
role as the glue A RRs already in use to solve the analogous problem
with finding the IP address of a name server.
6. Acknowledgments
Most of the ideas in this document were derived from email
conversations with Martha Steenstrup and Robert Woodburn, without
whose help the author would still be completely clueless about IDPR
and its requirements.
7. Author's address:
Rob Austein
Epilogue Technology Corporation
268 Main Street, Suite 283
North Reading, MA 01864
<sra@epilogue.com>
8. References
[1] IDPR specifications, currently another Internet Draft.
[2] DNS specifications, RFCs 1034 & 1035.
[3] DNS administrators guide, RFC 1033.